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(54) Network-independent connection management 



(57) In a telecommunications system (8) that com- 
prises communications endpoints (14-15), communica- 
tions resources (18-20), a communications server (10) 
that includes a media manager (21), and a network (12) 
that interconnects them ail, a first endpoint (14) pro- 
vides the media manager with an offer of a connection 
to a second endpoint (15) that specifies attributes 
desired for the connection by the first endpoint. The 
media manager registers the request and forwards it to 
the second endpoint. When the second endpoint 
responds with an acceptance of the connection that 
specifies attributes desired for the connection by the 
second endpoint, the media manager compares the 
registered offer with the received acceptance to deter- 
mine any resources that are needed to bridge any differ- 
ences between their attributes and to effect the 



connection. The media manager then marshals any 
needed resources for the connection, sends a modified 
acceptance to any marshaled resource telling it the 
address of the second endpoint to connect to, sends a 
modified acceptance to the first endpoint that tells it the 
address of any marshaled resource, or of the second 
endpoint in the absence of any marshaled resource, to 
connect to, and leaves it up to the endpoints and mar- 
shaled resources to interact with the network to effect 
the connection through the network. The media man- 
ager can therefore provide centralized call control for 
substantially any network, and can treat ail networks 
generically and leave it up to the endpoints to deal with 
the particulars of any specific network. Communications 
between multiple such telecommunications systems (8, 
9) can also be effected thereby. 
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Description 
Technical Field 

This invention relates to telecommunications. 

Background of the Invention 

The client-server architecture is becoming preva- 
lent in transaction-processing systems, including tele- 
communications systems. In the client-server 
architecture, an endpoint computing device or software, 
called a "client", uses the resources that are controlled 
or managed by another computing device or software, 
called a "server", that is networked with the client by a 
network fabric (e.g., a local area network (LAN), a met- 
ropolitan area network (MAN), a wide area network 
(WAN), or even a conventional telephony switching net- 
work). The client requests and receives information, 
services, and/or use of physical resources, from the 
server. 

Typically in telecommunications systems, call-con- 
trol servers have direct control over the telecommunica- 
tions networks connection-implementing (e.g., 
switching) fabric. When client endpoints make call 
requests to a call-control server, they specify their 
requirements to the server, and the server effects the 
requisite network connections through the network fab- 
ric. In order to do so, the call-control server must be tai- 
lored to the network fabric that it is controlling. Hence, 
different servers must be designed for different network 
fabrics. Moreover, most LANs, MANs, and WANs oper- 
ate in a distributed fashion, wherein each entity that is 
connected to the network has substantially equal con- 
trol over the network fabric as any other entity. Conse- 
quently, control of the network via a server (i.e., 
centralized control) is not only contrary to the design 
philosophy of the networks, but it is often also difficult to 
implement. 

Attempts have been made to remove the connec- 
tion-control function from a network central controller 
and distribute it among network endpoints. An illustra- 
tive example thereof is disclosed in U. S. Patent no. 
4,631,534. This patent discloses a distributed packet- 
switching system wherein a packet-switch controller 
acts as an address server for endpoint-station clients. 
When one (a calling) station wishes to communicate 
with another (a called) station, the network port of the 
calling station sends the calling and called station iden- 
tifiers to the packet-switch controller. The controller 
translates the identifier of the called station into a 
packet-switching network address of the called station 
and sends the network address to the port of the calling 
station. The port of the calling station saves the network 
address and uses it to send packets to the called station 
through the packet-switching network. 

An unfortunate limitation of arrangements such as 
this is that they require the calling and called endpoints 
to be directly interconnected by the network fabric, with- 



out intermediacy of any server, resource, gateway to 
another fabric, etc., that effectively functions as an inter- 
mediate endpoint. Consequently, such arrangements 
have severe limits as to the environments in which they 
5 may be used. 

Summary of the Invention 

This invention is directed to solving these and other 

io problems and disadvantages of the prior art. Illustra- 
tively according to the invention, in a client-server type 
of telecommunications system, the client endpoints 
make their requests and acceptances to the call-control 
server as before for communications connections hav- 

75 ing desired attributes, but rather than setting up the 
communications connections through the network, the 
server sends back instructions to the endpoints to ena- 
ble them to themselves cause the network to effect the 
requisite connections. In addition, the server allocates 

20 and assigns (i.e. , marshals) to the connection any com- 
munications resources that are needed to effect the 
connection through the network. Call connection man- 
agement can thus be extended by a call-control server 
over substantially any kind of network, and the server 

25 can treat the network generically, like any other network. 
Yet, at the same time, call connection management can 
be centralized in the server, instead of having to be 
embedded in each network control element (e.g.. end- 
point, resource, or switch). Further advantages are that 

30 separate call-control servers can be connected together 
via substantially any underlying transport network and 
cooperate to form a network of call controllers; that 
telephony-like, large and feature rich, networks can be 
constructed as a transparent overlay over less-sophisti- 

35 cated networks such as the Internet; and that features 
can be developed which transparently inter-work 
between different types of networks. 

Generally according to the invention, there is pro- 
vided a communications-connection manager for a tele- 

40 communications system that includes a plurality of 
communications endpoints that are capable of setting 
up communications, a set of communications 
resources, and a communications medium that inter- 
connects the endpoints and the resources. The man- 

45 ager effects connection management as follows. In 
response to receiving from a first endpoint an offer of a 
communication between the first and a second endpoint 
plus attributes of the communication desired by the first 
endpoint, the manager sends the offer to the second 

so endpoint. In response to receiving from the second end- 
point an acceptance of the offer plus attributes of the 
communication desired by the second endpoint, the 
manager determines any resource that is required to 
bridge any differences between the attributes of the 

55 offer and the attributes of the acceptance and to effect 
the communication. The manager then marshals any 
determined resource for the communication, and sends 
either to the first endpoint or to the second endpoint 
instructions for that endpoint to set up the communica- 
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tion between the endpoints on the medium through any 
marshaled resource. Illustratively, the manager sends to 
the first endpoint an acceptance of the offer that 
includes the instructions, and the instructions comprise 
either an address of a marshaled resource, or an 5 
address of the second endpoint in the absence of any 
marshaled resource. Illustratively, the manager also 
sends to the marshaled resource instructions for setting 
up the communication between the marshaled resource 
and the second endpoint, and the instructions comprise 10 
the address of the second endpoint. It is then up to the 
endpoint and any marshaled resource that receives the 
instructions to set up the communication on the medium 
between the first and second endpoints through any 
marshaled resource according to the received instruc- 75 
tions. 

Advantageously, the telecommunications system 
characterized above forms only one zone of a larger tel- 
ecommunications system that includes a plurality of 
zones. Included among the resources of the one zone is 20 
at least one resource for interconnecting the medium 
with a second communications medium of a second 
zone that comprises at least one communications end- 
point connected to the second medium and a second 
communications-connection manager for managing 25 
communications connections on the second medium, 
whereby a plurality of the zones and communications- 
connection managers can be networked to form an 
extended telecommunications system. 

These and other advantages and features of the 30 
present invention will become more apparent from the 
following description of an illustrative embodiment of the 
invention taken together with the drawing. 

Brief Description of the Drawing 35 

FIG. 1 is a block diagram of a telecommunications 
system that includes an illustrative embodiment of 
the invention; and 

FIGS. 2-4 are a functional flow diagram of opera- 40 
tions of endpoints and servers of the telecommuni- 
cations system of FIG. 1 in implementing the 
illustrative embodiment of the invention. 

Detailed Description 45 

FIG. 1 shows a telecommunications system config- 
ured according to the invention. The system includes 
one or more communications sub-systems, or zones 8- 
9. Zone 8 includes a first communications network 12 50 
that interconnects a plurality of first communications 
endpoints 14-15 with each other, with a first call-control 
server 10, and with first communications resources 19- 
20. Zone 9 includes a second communications network 
13 that interconnects a plurality of second communica- 55 
tions endpoints 16-17 with each other, with a second 
call-control server 11, and with second communications 
resources 22-23. The telecommunications system also 
includes a third network 18 that interconnects networks 
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12 and 13 to provide inter-zone communications 
between zones 8 and 9. While, for simplicity, only two 
zones 8-9 are shown as being interconnected by net- 
work 18, the system of FIG. 1 can comprise any number 
of interconnected zones. Ports 27 and 28 of resources 
20 and 23, respectively, interface and interconnect net- 
works 12 and 13, respectively, with network 18. Servers 

10 and 11 provide communications services, such as 
media managers 21 and 24, respectively, for communi- 
cations media (such as audio, video, distributed data, 
and shared data). Both endpoints 14-17 and servers 1 0- 

1 1 are stored-program-controlled devices that conven- 
tionally include interfaces to the external world, memory 
for storing control programs, and processors for execut- 
ing the stored control programs and for controlling the 
interfaces. Illustratively, endpoints 14-17 are multimedia 
workstations, such as Sun or Hewlett-Packard worksta- 
tions, networks 12-13 are LANs, MANs, WANs, or any 
other network-interconnect fabric, servers 10-11 are the 
Lucent Technologies MMCX multimedia communica- 
tions exchanges, resources 19-20 and 22-23 are com- 
munications-resource and communications-function 
providers, such as protocol converters, conferencing 
circuits, gateways to other networks, etc., and network 
18 is an inter-working transport medium, such as the 
Internet. Alternatively, network 18 is an equivalent of 
networks 12 and 13, with its own server (not shown) 
wherein resources 20 and 23 function as endpoints of 
network 1 8. Resources 20 and 23 are gateways from 
networks 12 and 13. respectively, to network 18 to 
which they connect through inter-network communica- 
tions ports 27 and 28, respectively. 

More detail about the illustrative implementation of 
servers 10 and 11 in the form of the Lucent Technolo- 
gies MMCX exchange may be found in a patent applica- 
tion of F. J. Boyle III et al. entitled "Arrangement for 
Facilitating Plug-and-Play Call Features", serial no. 
, filed on May 31, 1996 (concur- 
rently herewith), and assigned to the same assignee as 
this application, which is hereby incorporated herein by 
reference. 

Illustratively, server 10 and either resources 19 or 
20, or server 1 1 and either resources 22 or 23, may be 
co-located in a single programmable system. 

In the case of each server 10-11 being an MMCX 
exchange, ports 27 and 28 are co-located with media 
managers 21 and 24 on servers 1 0 and 1 1 , respectively. 
Media manager 21 and 24 of each server 10 and 11 
knows about all active resources 19-20 and 22-23, 
respectively, on its network 12 and 13, respectively: 
each resource registers with its server's media manager 
when the resource becomes active. Each server 10-11 
provides an infrastructure for bringing parties and multi- 
media services into communications "contexts" which 
provide bases for negotiation of service parameters. A 
context is a data representation of a "cyberspace meet- 
ing room". Each communications session (e.g., a multi- 
media call) is represented by its own context, a copy 25- 
26 of which exists in server 10-11 of each network 12- 
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13 that is involved in the session. All communications 
take place within a context, and parties (users and their 
endpoints) and services (service managers, such as 
media managers 21 and 24) are joined to one another 
as members within the context by the servers. A remote 5 
network is represented in a context by a port 27, 28 that 
connects the session to the remote network. The con- 
text service is somewhat analogous to Microsoft corpo- 
ration's Windows™ system. Just as the Windows 
system distributes events that reflect a change in the 10 
applications' presentation environment to all applica- 
tions running in the environment, so does the context 
distribute events which reflect a change in the commu- 
nications context to all members of the context. As part 
of the event-notification mechanism, context also sup- 15 
ports negotiation among context members to enable 
interworking of endpoints and service managers with 
possibly-disparate capabilities. 

According to the invention, network-independent 
connection management is implemented by endpoints 20 
1 4-1 7, servers 10-1 1 , and resources 1 9-20 and 22-23 in 
the system of FIG. 1 through an exchange of connection 
offers and acceptances. Each offer and each accept- 
ance may include one or more separate messages. 
Each offer and acceptance includes addresses and 25 
attributes. In the case of an offer, the addresses include 
an identifier of the offeror (the originator of the offer) and 
an identifier of the offeree (the intended recipient of the 
offer). The identifier of the offeree may be an identifier of 
a context of which the offeror is a member. Alternatively, 30 
the offer may contain one or more identifiers of only cer- 
tain members of the context as being the offerees. In the 
case of an acceptance, the addresses include an iden- 
tifier of the offeror whose offer is being accepted and ini- 
tially an identifier of the acceptor (the offer-accepting 35 
offeree). Offer and acceptance attributes may include 
some or all attributes of the proposed connection, such 
as the media type (e.g., audio, video, distributed data, 
shared data), class or quality of service, bandwidth, etc. 
(Some attributes may be assumed, and hence need not 40 
be conveyed.) The attributes may be conveyed by mes- 
sages separate from the messages that convey the 
addresses, or attributes and addresses may be con- 
veyed by the same messages. The exchange of offers 
and acceptances may be effected through substantially 45 
any desired communication protocol over networks 12 
and 13, or even over a separate signaling network. One 
such suitable protocol is the transfer control protocol 
(TCP). Another suitable protocol is the RSVP protocol 
modified to extend the information carried by the proto- so 
col beyond bandwidth-allocation information to informa- 
tion needed for communication-attribute negotiation. A 
description of the RSVP protocol may be found in 
"Resource ReSerVation Protocol (RSVP)-Version 1 
Functional Specification", an Internet- Draft of the Inter- 55 
net Engineering Task Force (IETF), dated November 
22, 1995. 

After a party's endpoint has joined a context 25, it 
has the ability to make offers of communications con- 
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nections to other parry's endpoints. Offers of different- 
media connections are made on an as-needed basis, 
e.g. , upon request from a party that is a context member 
to his or her endpoint. An offer is made by sending a 
message to a media manager of the local network's 
server. Upon being induced to make an offer, at step 
200, an endpoint (let us assume endpoint 1 4) generates 
an offer message and populates its address and 
attribute fields with values that define who is to be con- 
nected (let us assume endpoint 14 with endpoints 15 
and 16) and by what sort of a connection, at step 202. 
Endpoint 14 then sends the offer message to media 
manager 21 which is a member of context 25 that end- 
point 14 is also a member of, in its local server 10, at 
step 204. 

Upon receiving the offer message, at step 206, 
media manager 21 registers the offer for future use, at 
step 208, and then forwards the offer message to other 
entities that are involved in the communications ses- 
sion, that is, to other members of context 25 (let us 
assume endpoint 15 and port 27 on behalf of endpoint 
16 of network 13), at step 210. If the offer is addressed 
to only certain context members, media manager 21 for- 
wards the offer message to only the addressed mem- 
bers; if the offer is addressed to the communications 
session as a whole, media manager 21 forwards the 
offer message to all context members except the one 
from whom it had received the offer message. 

If one or more of the context members to whom the 
offer message is to be forwarded is a remote offeree 
one located in remote network 13-, as indicated at step 
211, media manager 24 of server 11 receives the offer 
via network 18 and ports 27 and 28 and processes the 
offer in the same manner as did media manager 21 of 
server 10. That is, upon receiving the offer message, at 
step 206, media manager 24 registers the offer, at step 
208, and then forwards the offeree message to other 
members of context 26 (endpoint 16) other than the one 
from whom it had received the offer message (port 28), 
at step 210. 

Upon receiving the offer message, at step 212, 
each endpoint offeree (endpoints 15 and 16) processes 
the offer according to its own procedures and parame- 
ters, at step 214. This may involve notifying a user of 
endpoint 15 or 16 that the offer has been received. If 
and when processing of the offer results in acceptance 
of the offer (e.g., the user of the endpoint indicates 
acceptance) at the endpoint, as determined at step 21 6, 
the acceptor (i.e., the accepting offeree) 15, 16 gener- 
ates an acceptance message and populates its address 
and attribute fields with values that define who the offe- 
ror and acceptor are and what sort of a connection the 
acceptor is willing to accept, at step 218. The attributes 
of the accepted connection may or may not be the same 
as the attributes of the offered connection. The acceptor 
15, 16 then sends the acceptance message to media 
manager 21 , 24 in its local server 1 0, 1 1 , respectively, at 
step 220. The acceptor's involvement in the offer- 
acceptance procedure then ends, at step 222. 
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Upon receiving the acceptance message, at step 
224, the media manager of the local server (media man- 
ager 21 of server 10 with respect to endpoint 15 and 
media manager 24 of server 1 1 with respect to endpoint 
16), analyzes the offer, at step 226, to determine what 
services and resources of the local network 12, 13 the 
accepted connection requires, at step 302. Media man- 
ager 21, 24 also compares the acceptance with the 
original offer to discover whether there are any differ- 
ences between the offer and the acceptance and what 
they are, at step 300, in order to determine what 
resources 19-20, 22-23 are needed to bridge any differ- 
ences between the offer and the acceptance, at step 
302. Media manager 21, 24 then determines, based on 
resources that are registered with that media manager 
21, 24, whether it can provide all of the needed 
resources, at step 304. If not, media manager 21, 24 
checks the offeror's address to determine whether it is 
in the offeror's local server, at step 306. If it determines 
that it is in the offeror's local server (i.e., server 10 in the 
assumed case of offeror 14), it proceeds to FIG. 4 to 
abort the planned connection. 

If media manager 21, 24 either determines at step 
304 that it can provide all needed resources, or if it 
determines at step 306 that it is not in the offeror's local 
server, media manager 21 , 24 proceeds to step 308 to 
marshal the requisite resources, e.g.. to allocate and 
assign them to the proposed connection. For example, 
if the connection must be made through another net- 
work, the media manager assigns the bandwidth that is 
required by the connection to the local port 27 or 28 that 
connects the local network to the remote network; if the 
offer specifies, an A-law audio connection while the 
acceptance specifies a n-law audio connection, the 
media manager assigns a protocol-converter from 
resources 19-20, 22-23 to the connection; and if the 
connection involves more than two entities on the media 
manager's network, the media manager assigns a con- 
ference bridge from resources 19-20, 22-23 to the con- 
nection. Media manager 21, 24 then generates a 
version of the received acceptance for each resource in 
its network that was marshaled at step 308, at step 310. 
For each resource, its version of the acceptance has an 
address of the entity that will be the recipient of the out- 
put of the resource as the acceptor address, and has 
the attributes that are required of the output of the 
resource as the attributes. Continuing the above exam- 
ple, when media manager 24 assigns a port 28 of the 
requisite bandwidth to the connection, media manager 
24 changes the identifier of the acceptor to the assigned 
port 28; if media manager 21 or 24 assigns an A-law/^- 
law protocol converter to the connection, then media 
manager 21 or 24 changes the identifier of the acceptor 
to the assigned protocol converter of resources 19-20 or 
22-23. respectively, and changes the acceptance 
attributes from u-law to A-law; and when media man- 
ager 21 assigns a conference bridge to the connection, 
it changes the identifier of the acceptor to the assigned 
conference bridge of resources 19-20. Media manager 



21 , 24 then sends the adjusted acceptances to the mar- 
shaled resources, at step 312. 

Upon receipt of the adjusted acceptance, at step 
320, each receiving resource processes the accept- 

5 ance, at step 322, using the attributes of the acceptance 
to set itself up so as to provide the requisite output. 
Each receiving resource also uses the acceptor 
address in its received acceptance to set up a call path 
to that address, at step 324. 

w Following step 312, media manager 21, 24 also 
sends an adjusted acceptance toward the offeror, at 
step 314. Its involvement in the offer-acceptance proce- 
dure then ends, at step 316. As indicated at step 318, 
media manager 21 of the offeror's local server 10 sends 

15 the adjusted acceptance to offeror endpoint 14, while 
media manager 24 of a remote server 1 1 sends the 
adjusted acceptance to the port 28 that connects the 
subject communications session through network 1 8 to 
network 12. The port 27 that receives the acceptance 

20 from port 28 passes it on to media manager 21 of server 
10, which responds as shown and described at steps 
224 et seq. 

Upon receiving the acceptance from media man- 
ager 21 , at step 330, offeror endpoint 14 processes the 

25 acceptance, at step 332, to ready itself for the proposed 
connection. Endpoint 14 then interacts with the local 
network 12. in whatever manner is dictated by the net- 
work 12, to cause network 12 to set up a connection 
between endpoint 14 and whatever entity (e.g., end- 

30 point 15, resource 19, or a port 27) is identified as the 
acceptor in the acceptance, at step 334. Involvement of 
endpoint 14 in the offer-acceptance procedure then 
ends, at step 336. 

Returning to step 306, if media manager 21 deter- 

35 mines that it is in the local server of the offeror and can- 
not provide all resources needed by the proposed 
connection, the proposed connection cannot be 
effected, and media manager 21 proceeds to FIG. 4 to 
abort it. Media manager 21 sends a rejection toward the 

40 acceptor that is identified in the message, at step 400, 
and also to the offeror -endpoint 14- at step 402. Its 
involvement in the offer-acceptance procedure then 
ends, at step 404. 

In response to receiving the rejection, at step 420, 

45 offeror endpoint 14 processes the rejection, at step 422 
(e.g., it notifies its user that the desired connection can- 
not be made), and ends the offer-acceptance proce- 
dure, at step 424. 

If the acceptor is local, e.g., endpoint 15, as indi- 

50 cated at step 401 , it receives the rejection directly from 
media manager 21, at step 410. If the acceptor is 
remote, first the media manager 24 of remote server 1 1 
receives the rejection from media manager 21 of local 
server 10 through port 28. at step 430. In response. 

55 media manager 24 sends the rejection toward the 
acceptor, at step 432. If the acceptor is local - endpoint 
16 in this example - as indicated at step 433, it receives 
the rejection directly, at step 410. if the acceptor were 
remote, it would receive the rejection indirectly, through 
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its own media manager, at steps 430 et seq. Upon 
receipt of the rejection, at step 410, the acceptor proc- 
esses the rejection, at step 412, and then ends its 
involvement in the proposed connection, at step 414. 

Further in response to receipt of the rejection, 
media manager 24 of remote server 1 1 sends the rejec- 
tion to the resources that it had marshaled at step 308, 
at step 434, frees the marshaled resources from assign- 
ment to the subject connection for use by other connec- 
tions, at step 436, and then ends its involvement in the 
offer-acceptance process, at step 438. Upon receipt of 
the rejection, at step 440, each resource tears down the 
call-path segment that it had setup at step 324, at step 
442, and ends its involvement in the proposed connec- 
tion, at step 444. 

Of course, various changes and modifications to 
the illustrative embodiment described above will be 
apparent to those skilled in the art. For example, instead 
of the acceptance including the address to which the 
offeror must attach, the offer may include the address to 
which the acceptor must attach, whereby the call path is 
formed in the reverse direction from the one disclosed 
above. Or, offer attributes and acceptance attributes 
may be communicated to the servers in messages that 
are separate from the messages that convey the 
addresses along the call path, and the attribute mes- 
sages need not follow the call path -- they may be com- 
municated to the servers via a separate signaling 
network, for example. Also, instead of using the context 
of the MMCX exchange as the messaging mechanism 
for offers and acceptances, any other desired messag- 
ing mechanism may be used. One suitable alternative 
mechanism is the multipoint communications services 
(MCS) protocol which is described in the ITU T.120 pro- 
tocol series. Such changes and modifications can be 
made without departing from the scope of the invention 
and without diminishing its attendant advantages. 

Claims 

1. A communications-connection manager (10) for a 
telecommunications system (8) that includes a plu- 
rality of communications endpoints (14-15) that are 
capable of setting up communications according to 
received instructions, a set of communications 
resources (18-20), and a communications medium 
(12) interconnecting the endpoints and the 
resources, CHARACTERISED BY: 

means (21 :206-21 1) responsive to receipt from 
a first endpoint of an offer of a communication 
between the first and a second endpoint and 
attributes of the communication desired by the 
first endpoint, for sending the offer to the sec- 
ond endpoint; 

means (21 :224-306) responsive to receipt from 
the second endpoint of an acceptance of the 
offer of the communication and attributes of the 
communication desired by the second end- 



point, for determining any resource that is 
required to bridge any differences between the 
attributes of the offer and the attributes of the 
acceptance and to effect the communication; 

5 means (21 :308) responsive to the determina- 

tion, for marshaling any determined resource 
for the communication; and 
means (21:310-318) responsive to the mar- 
shaling, for sending to one of the first endpoint 

10 and the second endpoint instructions for the 

one endpoint to set up the communication 
between the one endpoint and another of the 
first endpoint and the second endpoint on the 
medium through any marshaled resource. 

15 

2. The manager of claim 1 wherein: 

the means for sending instructions comprise 
means (21:314) in the manager responsive to 
20 the marshaling, for sending to the first endpoint 

an acceptance of the offer including instruc- 
tions for the first endpoint to set up the commu- 
nication through any marshaled resource. 

25 3. The manager of claim 1 for a telecommunications 
system wherein the resources have addresses on 
the communications medium, wherein: 

the means for sending instructions comprise 
30 means (21 :314) in the manager responsive to 

the marshaling, for sending to the one endpoint 
instructions for the one endpoint to set up the 
communication to the other endpoint through 
the address of any marshaled resource. 

35 

4. The manager of claim 1 for a telecommunications 
system wherein the endpoints and the resources 
have addresses on the communications medium, 
wherein: 

40 

the means for sending instructions comprise 
means (21:314) in the manager responsive to 
the marshaling, for sending to the one endpoint 
the address of at least one of (a) a marshaled 
45 resource and (b) the other endpoint. 

5. The manager of claim 1 for a telecommunications 
system wherein the resources are capable of set- 
ting up communications according to received 

so instructions, wherein: 

the means for seeding instructions comprise 
means (21:312-314) in the manager respon- 
sive to marshaling of at least one resource for 
55 the communication, for sending to the mar- 

shaled resource an acceptance of the offer 
including instructions for the marshaled 
resource to set up a communication between 
the marshaled resource and the second end- 
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point, and for sending to the first endpoint an 
acceptance of the offer including instructions 
for the first endpoint to set up a communication 
between the first endpoint and the marshaled 
resource, and further responsive to marshaling 
of no resource for the communication, for send- 
ing to the first endpoint an acceptance of the 
offer including instructions for the first endpoint 
to set up a communication directly between the 
first endpoint and the second endpoint. 

6. The manager of claim 1 for a telecommunications 
system that includes among the resources at least 
one means (18) for interconnecting the medium 
with a second communications medium (13) of a 
second communications system (9) that comprises 
at least one communications endpoint (16-17) con- 
nected to the second medium and a second com- 
munications-connection manager (11) for 
managing communications connections on the sec- 
ond medium. 

7. A telecommunications system (FIG. 1) comprising: 

a first communications endpoint (14); 

a set of first communications resources (19- 

20); 

a first communications medium (12) intercon- 
necting the first endpoint and the first 
resources; 

a second communications endpoint (16); 

a set of second communications resources 

(22-23); 

a second communications medium (13) inter- 
connecting the second endpoint and the sec- 
ond resources; and 

means (18) for interconnecting the first medium 
with the second medium; 

CHARACTERISED BY 
a first communications-connection manager 
00); 

a second communications-connection man- 
ager (11); 

means (14:202-204) in the first endpoint for 
sending to the first manager an offer of a com- 
munication between the first and the second 
endpoints and attributes of the communication 
desired by the first endpoint; 
means (21:206-211) in the first manager 
responsive to receipt of the offer, for sending 
the offer to the second manager; 
means (24:206-211) in the second manager 
responsive to receipt of the offer, for sending 
the offer to the second endpoint; 
means (16:212-220) in the second endpoint 
responsive to receipt of the offer, for sending to 
the second manager an acceptance of the offer 
and attributes of the communication desired by 
the second endpoint; 
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means (24:224-302) in the second manager 
responsive to the received offer and to receipt 
of the acceptance, for determining any second 
resource that is required to bridge any differ- 
ences between the attributes of the offer and 
the attributes of the acceptance and to effect 
the communication; 

means (24:308) in the second manager 
responsive to the determination, for marshaling 
any determined second resource for the com- 
munication; 

means (24:310-318) in the second manager 
responsive to the marshaling, for sending to 
one of the interconnecting means and the sec- 
ond endpoint first instructions for the one of the 
interconnecting means and the second end- 
point to set up the communication between the 
one of the interconnecting means and the sec- 
ond endpoint on the second medium through 
any marshaled second resource; 
the one of the interconnecting means and the 
second endpoint being responsive to receipt of 
the first instructions for setting up (320-336) the 
communication on the second medium accord- 
ing to the first instructions; 
means (24:310-318) in the second manager 
responsive to the marshaling, for sending to the 
first manager an acceptance of the offer and 
the attributes of the acceptance modified for 
those attributes bridged by any second 
resource marshaled by the second manager ; 
means (21:224-306) in the first manager 
responsive to the received offer and to receipt 
of the acceptance, for determining any first 
resource that is required to bridge any differ- 
ences between the attributes of the offer and 
the modified attributes of the acceptance and 
to effect the communication; 
means (21 :308) in the first manager responsive 
to the determination, for marshaling any deter- 
mined first resource for the communication; 
means (21:310-318) in the first manager 
responsive to the marshaling, for sending to 
one of the interconnecting means and the first 
endpoint second instructions for the one of the 
interconnecting means and the first endpoint to 
set up the communication between the one of 
the first endpoint and the interconnecting 
means on the first medium through any mar- 
shaled first resource; and 
the one of the interconnecting means and the 
first endpoint being responsive to receipt of the 
second instructions, for setting up (320-336) 
the communication on the first medium accord- 
ing to the second instructions. 

A method of managing communications connec- 
tions in a telecommunications system (8) that 
includes a plurality of communications endpoints 



BNSDOCID: <EP O812069A2_l_> 



13 EP0 812 

(14-15), a set of communications resources (18- 
20), a communications medium (12) interconnect- 
ing the endpoints and the resources, and a commu- 
nications-connection manager (10), the method 
CHARACTERISED BY the steps of: 5 

sending (200-202) an offer of a communication 
between a first and a second endpoint and 
attributes of the communication desired by the 
first endpoint from the first endpoint to the man- w 
ager; 

in response to receipt of the offer by the man- 
ager, sending (206-211) the offer from the 
manager to the second endpoint; 
in response to receipt of the offer by the second is 
endpoint, sending (212-220) an acceptance of 
the offer and attributes of the communication 
desired by the second endpoint from the sec- 
ond endpoint to the manager; 
in response to receipt of the acceptance by the 20 
manager, determining (224-306) at the man- 
ager any resource that is required to bridge any 
differences between the attributes of the offer 
and the attributes of the acceptance and to 
effect the communication; 25 
in response to the determination, marshaling 
(308) any determined resource for the commu- 
nication by the manager; 
in response to the marshaling, sending (310- 
318) instructions for one of the first endpoint 30 
and the second endpoint to set up the commu- 
nication between the one endpoint and another 
of the first endpoint and the second endpoint 
through any marshaled resources from the 
manager to the one endpoint; and 35 
in response to receipt of the instructions by the 
one endpoint, the one endpoint setting up (320- 
336) the communication between the first and 
second endpoints through any marshaled 
resource on the medium according to the 40 
received instructions. 

9. A method of managing communications connec- 
tions in a telecommunications system that includes 
a first communications endpoint (14), a set of first 45 
communications resources (19-20), a first commu- 
nications medium (12) interconnecting the first end- 
point and the first resources, a first 
communications-connection manager (10) for the 
first medium, a second communications endpoint so 
(16), a set of second communications resources 
(22-23). a second communications medium (13) 
interconnecting the second endpoint and the sec- 
ond resources, a second communications-connec- 
tion manager (11) for the second medium, and 55 
means (18) for interconnecting the first medium 
with the second medium, the method CHARAC- 
TERISED BY the steps of: 
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sending (202-204) an offer of a communication 
between the first and the second endpoints and 
attributes of the communication desired by the 
first endpoint from the first endpoint to the first 
manager; 

in response to receipt of the offer by the first 
manager, sending (206-21 1) the offer from the 
first manager to the second manager; 
in response to receipt of the offer by the second 
manager, sending (206-21 1) the offer from the 
second manager to the second endpoint; 
in response to receipt of the offer by the second 
endpoint, sending (212-220) an acceptance of 
the offer and attributes of the communication 
that are desired by the second endpoint from 
the second endpoint to the second manager; 
in response to receipt of the offer and the 
acceptance by the second manager, determin- 
ing (224-306) at the second manager any sec- 
ond resource that is required to bridge any 
differences between the attributes of the offer 
and the attributes of the acceptance and to 
effect the communication; 
in response to the determination, marshaling 
(308) any determined second resource for the 
communication by the second manager; 
in response to the marshaling, sending (310- 
318) first instructions for one of the intercon- 
necting means and the second endpoint to set 
up the communication between the one of the 
interconnecting means and the second end- 
point on the second medium through any mar- 
shaled second resource from the second 
manager to the one of the interconnecting 
means and the second endpoint; 
in response to receipt of the first instructions by 
the one of the interconnecting means and the 
second endpoint, setting up (320-336) the 
communication on the second medium accord- 
ing to the first instructions by the one of the 
interconnecting means and the second end- 
point; 

in response to the marshaling, sending (310- 
318) an acceptance of the offer and the 
attributes of the acceptance modified for those 
attributes bridged by any second resource mar- 
shaled by the second manager from the sec- 
ond manager to the first manager; 
in response to receipt of the offer and of the 
acceptance by the first manager, determining 
(224-306) any first resource that is required to 
bridge any differences between the attributes 
of the offer and the modified attributes of the 
acceptance and to effect the communication at 
the first manager; 

in response to the determination, marshaling 
(308) any determined first resource for the 
communication by the first manager; 
in response to the marshaling, sending (310- 
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318) second instructions for one of the inter- 
connecting means and the first endpoint to set 
up the communication between the one of the 
first endpoint and the interconnecting means 
on the first medium through any marshaled first 5 
resource from the first manager to the one of 
the interconnecting means and the first end- 
point; and 

in response to receipt of the second instruc- 
tions at the one of the interconnecting means 10 
and the first endpoint, setting up (320-336) the 
communication on the first medium according 
to the second instructions by the one of the 
interconnecting means and the first endpoint. 
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